By -  A Customer

Raymond does a good job of explaining the philosophy driving the Unix-style of programming. Coming from a background programming Windows, I always thought of the Unix approach (lots of abbreviated command-line utilities, mini-languages, pipes, semi-unstructured text-based process integration) as down-right primitive. However, after reading this book, I've started to understand the philosophy (and the practical reasons) for adopting this approach. I'd definitely recommend this book especially to newbie programmers from the Windows or Mac (pre-OS X) worlds. That said, I do have some criticisms:

One of the problems with this book is the overly partisan tone it takes - one gets the impression that absolutely nothing Microsoft has ever done is of value, but the other major desktop PC OSes (Apple, Linux) represent different forms of perfection. (At home, I run Mac OSX, RedHat Linux and Windows, and have a reasonable sense of their relative strengths and weaknesses.)

So, be warned: Art of Unix Programming paints a one sided picture. The author is a well-known figure in the open source community, one of its fiercest advocates, and one of Microsoft's most vocal critics, so it might seem to strange to wish for less anti-Microsoft spin from this source. After all, the Raymond brand certainly carries with it an obligatory expectation of Windows-bashing, doesn't it?

One of the only Windows design decision which Raymond doesn't condemn is the (now discontinued) .ini file format. Even the thorough-going support for object-orientation in Windows is given short-shrift: after explaining the many horrors of object-oriented programming (according to Raymond), Unix-programmers are praised as "tend[ing] to share an instinctive sense of these problems." This section (http://www.faqs.org/docs/artu/unix_and_oo.html) is particularly illustrative of the one-sided approach that Raymond takes.

Art of Unix Programming is really an excellent and informative book which could have been substantially better with a little balanced discussion. I found myself constantly second-guessing the author: Is he arguing such-and-such a point on the merits or because he simply loves UNIX & hates Microsoft so much? While the book does a great job of articulating and illustrating the UNIX idiom, it's a shame that the reading experience is marred by mistrust. If he hadn't been so blindly anti-Microsoft, we'd be able to more confidently rely on his conclusions, and the text would be not merely highly informative (as it is), but definitive (as it is not). Four stars, therefore, instead of five.